-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(event): Ability to create and sign events for use with js-ceramic #3
Conversation
What does "document" mean in this context?
|
Yep, this work so far focuses on commits, and then the format for stream id type document (3). I think what you're suggesting is
|
Yes, I think that's roughly what I said.
Not sure I follow this. js-ceramic should definitely be following the spec. cc @AaronGoldman |
@oed Reworked PR to match more closely with terms used in spec. As implemented, this can be used with js-ceramic for creating, updating, and reading MIDs. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great, I have a few comments/suggestions below.
My biggest question is how we can update the dag-jose
crate to be of use here.
} | ||
|
||
#[derive(Serialize, Deserialize)] | ||
pub struct Jws { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd like to understand what needs to change in the dag-jose
crate in order to be able to use its types here?
I understand this Jws
struct also add the signing/verification logic however I do not see the dag-jose
crate used anywhere in the code base. As such seems like we should fix that crate to make it amenable to this code as its purpose was to be a building block for Ceramic events.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I was really surprised once I got everything implemented, that the events we pass to ceramic don't actually use dag-jose. They just have the data so that ipfs can encode them as dag-jose.
Seems like there's a mismatch there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, feel free to merge when its green.
32b47bd
to
b27da17
Compare
ok I updated this PR to pass CI. There are two major changes:
Once #32 merged we can merge this PR |
pub struct Event { | ||
/// Cid of the data for the event | ||
pub cid: Cid, | ||
/// The data for the event to be encoded in the block | ||
pub linked_block: DagCborEncoded, | ||
/// JWS signature of the event | ||
pub jws: Jws, | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably don't need to change this now, but events can also contain one cacaoBlock
(currently), and possible multiple CACAO blocks in the future.
I wonder if a better structure for an event is just a CAR file with all the relevant IPLD blocks?
If not clear already: both jws
and linked_block
should be IPLD objects.
core/src/stream_id.rs
Outdated
/// Optional commit for this stream | ||
pub commit: Option<Cid>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to introduce "commitIds" yet (or at all)?
There is a painpoint around how commitIds are specified currently because they kind of break the multiformat nature of streamIds.
Me and @AaronGoldman talked about introducing a new way to reference a specific event inside of a streamId. This approach would allow streamIds to always be a real multiformat:
https://github.com/AaronGoldman/CIP/blob/stream-sets-synchronization/CIPs/CIP-124/cip-124.md#eventid-sort-order
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mainly have it there to make sure we can read cid's with commit id's specified. If we don't think we'll have stream id's with commits, I'd gladly remove it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
StreamIds with commits are not really used anywhere in the core protocol right now. They are mainly used to show the id of a commit to the user.
…amic Add event functionality (see https://developers.ceramic.network/protocol/streams/event-log/#events) which is similar to commit functionality currently found in ceramic.
No description provided.